Subject: Re: Open Item List

From: [email-masked] (Paul Brittain)
Date: Mon, 6 Jun 94 16:59:57 BST

Steve,

Your latest summary of the Connect RIGlet status does not mention the
following, admittedly fairly trivial, points from my mail of 22/5/94:

>-       Please document that the x1D 'Wide Area Hello' message used by MPNP 1.2
>        is of infoframe length and does not have a control header.
>
>        As a general point, we need to be careful about any SSP messages that
>        may flow using just the INFOFRAME header as DLS partners will get out of
>        synch on the TCP bytestream if they have different expectations for the
>        size of header used for any message type.  This is unavoidable if the
>        message length does not include the header, hence unrecognized message
>        types can only be assumed to have Control Message headers.
>
>-       Presumably the reverse is true for ENTER/EXIT BUSY and TEST CIRCUIT
>        messages - i.e. they use Control Message headers?
>

I know these messages will probably not be used in the standard, but if they
are to be documented as obsolete messages for backwards compatibility, then we
need to document them accurately for such compatibility to be possible.

Neither point seems very controversial, but if anyone disagrees, please post
details of any issues.

Thanks,

Paul Brittain
Data Connection.

---

From: Frank Bordonaro <[email-masked]>
Date: Mon, 6 Jun 94 10:25:18 PDT

Paul,

I would like to take your second point one step further.
Here is part of an eamil I sent to connect on 14 Mar 94 

> >The main problem is that the SSP Message Type field is overloaded.
> >It explicitly calls out the message type and implies the message
> >length based on the type. The problem arises when new message types
> >are defined and a new message type is sent to a dlsw peer that
> >does not recognize the new message type. The peer receiving the new
> >message will not recognize it and must guess at it's SSP header length.
> >If it guesses incorrectly, it will never get back in synchronization
> >with the TCP pipe to read the next SSP header.

I went on to suggest 

> >The second option is to add a new SSP header field to both control and
> >information headers called Message Header Length. This would allow
> >unrecognized SSP messages to be discarded and the next SSP header to
> >be read without difficulty.

This suggestion was greeted with a negative response because it changes
the SSP header format which does not sit well with vendors that have alrady 
implemented the SSP protocol. Backwards compatibility was the reason given 
why the header should not be changed.  I would like to point out again that
the standard begins when we reach closed pages. I understand the concerns of
vendors that have already implemneted the SSP protocol, but if we don't 
improve the standard because of this, we will only ever be as good as these
early implementations.

Steve, I would really like to see Paul's second point added to the list 
of Connect RIGlet items that need to be resolved. I support either adding
a 'SSP header length' field or re-defining 'Message Length' to include the
SSP header. I believe either solution will allow a switch to discard
unrecognized message types properly.

Thanks,
Frank Bordonaro
cisco Systems, Inc.